Are you proposing adding new top-level keys to the package.json? Could we just express need and desire with a new "required" prop in the (provided|consumed)Services keys? Something like this

autocomplete-plus

{
  "name": "autocomplete-plus",
  "consumedServices": {
    "autocomplete.provider": {
      "required": false,
      "versions": {
        "2.0.0": "consumeProvider"
      }
    }
  }
}

autocomplete-css

{
  "name": "autocomplete-css",
  "providedServices": {
    "autocomplete.provider": {
      "required": true,
      "versions": {
        "2.0.0": "getProvider"
      }
    }
  }
}

We could also call these requireConsumer and requireProvider, but it would be nice to have symmetry IMO.

Could we just express need and desire with a new required prop in the (provided|consumed)Services

Yep, that was the direction I was heading. I was also going to add a hint for a preferred or hinted package that satisfies the service dependency (i.e. it provides/consumes the service) that would be used if:

• The user doesn't already have a package installed
• The user hasn't expressed a preference for which package should be used to satisfy the service dependency

This would allow us to have the following user flows:

• The package you are installing requires a package that provides/consumes service <x>.
• The package you are installing has enhanced functionality <abc> that requires other package(s). Packages <a>, <b>, or <c> provide this functionality.
  • Choose 1
  • Choose many
• The package author has suggested that package <y> could be used to add additional functionality <abc> for the package you are installing. Would you like to install it? Packages <j>, <k>, <l> also add similar functionality.
• The package you have installed needs package(s) that provide service <z>. Packages <1>, <2>, <3> provide this functionality. Would you like to install any of these?

So far this is my preferred syntax for these concepts.

autocomplete-plus

{
  "name": "autocomplete-plus",
  "consumedServices": {
    "autocomplete.provider": {
      "requireProvider": true,
      "suggestedProviders": {},
      "versions": {
        "2.0.0": "consumeProvider"
      }
    }
  }
}

autocomplete-css

{
  "name": "autocomplete-css",
  "providedServices": {
    "autocomplete.provider": {
      "requireConsumer": true,
      "suggestedConsumers": {
        "autocomplete-plus": "^1.0.0"
      },
      "versions": {
        "2.0.0": "getProvider"
      }
    }
  }
}

The suggestedProviders field doesn't actually make sense for autocomplete-plus, but I included it for example purposes:

👍

I still think we could leave out the suggestedProviders and suggestedConsumers things, and instead just suggest providers/consumers based on popularity if the requireConsumer or requireProvider flag is true. This way things won't get as stale if something like autocomplete++ comes out.

bump To get the discussion moving again on this.

I would absolutely love to stop having to force users to install linter in linter-* plugin packages just so we know they have something capable of making the package work.

Although some of the arguments from #385 (comment) can be applied here, not all of them do so I'm wondering if that is why this was closed?

They are very different cases in my opinion, #385 was a way to install a group of packages at once, which might be useful for a user but doesn't really relate to this which was more along the lines of "I simply can't operate without something providing/consuming this service".

I still would love to get rid of the workaround of forcing a hardcoded list of packages to be installed using atom-package-deps, especially since there is already the case where there are two perfectly good consumers of the primary service I work with, and we are forcing one consumer to be installed (but not active) in every linter-* pacakge just to have a useable experience.

@Arcanemagus this is a good point, but I think apm is the wrong place to start solving the problem. I think this begins with a complete understanding of the desired user experience, from which we should work backwards to potentially add metadata to package.json and / or the atom.io API.

I completely agree that the scenario you describe is a big gap and leaves users with an undesirable outcome some (not-insignificant) portion of the time.

A lack of service suggestions is definitely on my radar as a huge shortcoming in our package system.

Just a bump that this feature would have solved a major headache with the upcoming launch of linter v2 as we could just mark updated providers as requiring the newer linter service consumer version.

As of now we are thinking of adding versioning support into atom-package-deps so updated providers can be ensured they will have a version of linter able to work with them, but haven't decided on a final solution yet.

Hear you loud and clear. It's on a pretty short list of things competing for my attention and I'm hoping another team member that's switching from another team within GitHub might help us make progress here fairly soon. /cc @iolsen

With the beta release of atom-ide-ui this is yet again becoming a major issue as currently all the linter-* providers request the installation of linter on startup as that was the only consumer of the service they provide out there.

Sure, that check can be removed once (if?) atom-ide-ui gets integrated into Atom core, but until then anyone trying to use a linter-* provider will be prompted with that dialog as there is no way to know that there is already a consumer of the service installed.

Any chance this could be worked on soon™️ or should I just be telling users "tough luck" until that check can be completely removed?

Could always refer users to the Consumers section at the top of the AtomLinter home page and let them choose their own consumer. 🤷‍♂️

Could always refer users to the Consumers section at the top of the AtomLinter home page and let them choose their own consumer.

Oh sure. That's an improvement. User comes to us for a service. We can't provide it without a consumer. So let's just send them away to a web browser, to a page full of choices, and no obvious hint as to which choice might be a good one or why. "Not my problem. Good luck to you." 🤦‍♂️